Тоже оживление приборов

[САБ 444]

Продолжаю разговор начатый в соседней теме. Shadow Builder вежливо попросил оттуда, поэтому свои результаты и идеи буду выкладывать здесь. Обсуждение и критика не возбраняются. В этом сообщении я постараюсь ответить на оставленные в той ветке неотвеченными посты fiyrus и vitabutch.

 

Итак, стоящая задача: создать кокпит Ми-8 с оживлением настоящих приборов, а при невозможности оживления - создание максимально правдоподобных имитаций. В качестве отправной точки имеется корпус кабины - останки какого-то тренажера. Строится все это даже не для себя, а для авиамузея, т.е. чистый альтруизм и практически никакого финансирования, поэтому цена комплектации - один из важных факторов.

 

В качестве управляющей программы выбран x-plane. Просьба этот пункт принять как данность и не обсуждать.

Архитектура системы видится следующая:

Электрически интерфейс разбит на две шины, одна для передачи данных от симулятора на индикаторы, вторая для передачи данных от органов управления в симулятор. Если прибор имеет и то и другое, то в него входят обе шины.

Поскольку на шине индикаторов только один мастер - коллизии исключены. В качестве интерфейса выбран RS485 по следующим соображениям:

1) Интерфейс полудуплексный, подходит при отсутствии коллизий.

2) Интерфейс предполагает наличие многих устройств (драйвер дешевых "обычных" SP491 рассчитан на 32 приемника), в отличие от RS232, который предназначен для соединения только двух устройств.

3) Используются диференциальные приемники и передатчики, рассчитаные на витую пару, отсюда следует хорошая помехозащищенность. Для fiyrus, комментарий на сообщение: резисторы-терминаторы на концах линии служат для согласования волнового сопротивления линии и следующего из этого исключения отражения сигналов от концов несогласованной линии. Отраженный сигнал накладывается на прямой и искажает его. Чем резче фронты сигнала, тем больше искажений внесет отраженный. Волновое сопротивление витой пары 120 Ом, именно поэтому номинал терминирующих резисторов выбирается таким, а не из соображений "чтобы ток побольше тек".

4) Недорогие драйвера, изначально рассчитанные на скорости более мегабита (SP491 - 5 Мбит). Предел для обычных драйверов RS232 - 115Кбит.

5) Интерфейс изначально рассчитан на большие расстояния.

Если не хватит пропускной или нагрузочной способности, то шина разбивается на две - приборы левого и правого пилотов.

Протокол с подтверждениями и повторами. Если устройство не подтвердило два повтора, оно считается неисправным и исключается из посылок на какое-то время (2-5 сек.).В прибор передается значение отображаемой физической величины. Поскольку каждый индикатор раз и навсегда жестко привязан к своему модулю управления, то все преобразования физ. величины в пупки, подающиеся на прибор с учетом всех калибровок происходят непосредственно в модуле.

 

 

В качестве интерфейса источников сигналов о положении органов управления, переключателей и т.п выбран CAN.

Часть причин описана в этом сообщении.

дополнительно: существуют небольшие контроллеры со встроенным модулем CAN ценой порядка 4 долл (их много у микрочипа). Снаружи требуется только драйвер розничной ценой в доллар. Это гораздо дешевле, чем реализовывать связь между контроллерами через эзернет.

На шине CAN мастеров много, но они передают свои данные с частотой 80 Гц (посоветована fiyrus в вышеупомянутой теме). Согласно моим расчетам в той же теме, все органы управления успеют передать свои состояния за 1/80 сек благодаря механизму разрешения коллизий, заложенному в CAN. Если частоты 80 Гц для каких-то датчиков будет мало, то можно разделить приборы на несколько групп, передающих информацию с разными периодами. Благодаря механизму приоритетов в CAN исключается блокирование сообщений от устройств с более высоким приоритетом устройствами с более низким. Для передачи необходимой информации достаточно 8 байтов сетевого уровня протокола CAN, поэтому никакие протоколы более высокого уровня поверх CAN не нужны.

 

В качестве соединителя этих шин с компьютером будет использоваться микросхема FT2232, на одном (или обоих) из UARTов которой будет висеть преобразователь UART-RS485 типа SP491 (у меня она есть, я их применяю) или MAX485 или аналогичный). К SPI-интерфейсу FT2232 будет подключаться CAN-контроллер MCP2515 и драйвер CAN MCP2551. Стоимость всех этих микросхем вместе на сегодняшний день в розницу в Риге около 10-20 долл.

 

Модуль управления каждым индикатором будет состоять из контроллера (ATmega8 / ATmega48/88 / АТ91SAM7S64), драйвера RS485 и выходного каскада. Для логометрических приборов - RC цепочка, для слаботочных приборов, требующих формирования трехфазного напряжания током до 1А - L293, для сильноточных - драйвера полевиков и полевики по аналогии с платой УАС из упомянутой выше ветки. По софту: софт будет состоять из двух частей - загрузчика, позволяющего обновлять прошивку прямо по интерфесу, без программатора, и собственно приложения, формирующего сигналы управления индикатором. Адрес каждого модуля будет жестко прошиваться на этапе изготовления одновременно с загрузчиком, благо программатор AVReal позволяет это делать автоматически. В протоколе планируется 5 команд: "идентификация", "посылка отображаемой величины", "чтение калибровок", "запись калибровок", "переход в режим загрузки". Загрузчик умеет отвечать только на команды "идентификация" и "переход в режим загрузки", приложение - на все. По команде "идентификация" прибор сообщает свой тип и номер версии прошивки (загрузчик сообщает номер версии ноль). Это позволяет найти все устройства на шине путем тупого перебора адресов и принять решение о необходимости обновления прошивки.

 

Модуль обслуживания органов управления будет состоять из драйвера CAN MCP2551, контроллера со встроенным CAN-контроллером (PIC24HJ64GP202 или аналогичного, цена около 4 долл.) или связки ATmega8/48/88 и MCP2515. Использование потенциометров для чтения положения РУ и Шаг/Газ считаю нецелесообразным из-за невысокой износостойкости потенциометров. Думаю реализовать датчики положения на том же принципе, на котором работают электронные штангенциркули.

 

В качестве шлюза между симулятором и FT2232 будет программа, которая со стороны FT2232 будет поддерживать протокол шин, а со второй стороны может иметь интерфейс как к x-plane, так и к MSFS или другому симулятору через любой протокол, если кто-то захочет его дописать. Хоть через IOCP,(для vitabutch: это протокол более высокого уровня и не имеет отношения к реализации шины, и я так и не понял, чему вы в нем восхищаетесь). Эта программа при необходимости будет однозначно и без всяких калибровок переводить пупки, посылаемые симулятором в физическую величину, посылаемую на индикатор. И обратно - градусы органа управления в пупки симулятора. Таким образом исключится необходимость калибровать прибор под каждый симулятор.

 

Все исходники будут открыты. В качестве компиляторов используется бесплатные avr-gcc (WinAVR), gcc (MinGW). Среда разработки схем и плат - планируется KiCAD, если мне удасться его освоить с моими многолетними пикадовскими привычками.

 

Ну и первые результаты: Судя по внешнему виду и внутреннему устройству, мне попался ИТЭ-1. Реализован загрузчик и формирование трехфазного синуса. Управление пока из терминалки (кнопками + и -) через RS232.

 

 

Макет контроллера: ATmega8, L293, 6 диодов SS12 (припаяны снизу), 78L05, 4 конденсатора, 1 резистор, светодиод. В корпусе разъема DB9 собран преобразователь UART-RS232, в боевой системе вместо него будет SP491.

[САБ 444]

Дополнение к фотографиям: в обмотки подается ШИМ с выхода драйвера без всякой фильтрации.

 

Первые пуски показали следующее: при резком увеличении частоты двигатель выходит из синхронизма и либо останавливается, либо начинает вращаться с примерно втрое меньшей скоростью. Для входа в синхронизм требуется понизить частоту до ~20% шкалы. Надо будет предусмотреть в программе контроллера ограничение на скорость изменения.

Завтра попробую хитрый метод формирования фазного напряжения, позволяющий получить ту же амплитуду межфазного напряжения при на 22% меньшем питании, вот такой:

черным показано напряжение с одного из выходов драйвера, голубым - напряжение между фазами.

Edited September 22, 2009 by САБ

[fiyrus 576]

Для передачи необходимой информации достаточно 8 байтов сетевого уровня протокола CAN...

==

Непонятно что вы передадите этими 8-ю байтиами. И еще поди небось за одну посылку ?...

Например одна ось - это 10 бит. Это минимум 2 байта. Тоесть получается передавать нужно за два прохода ..тоесть 80/2=40 раз в сек.

А осей таких миниумм 10 в кокпите.. Итого 40 герц /10 = 4 герца на каждую ось ? ..круто.. У нас все потенциально 65536 осей передаются с частотой 80 герц. Хоть одна , хоть все сразу..

[САБ 444]

Непонятно что вы передадите этими 8-ю байтиами. И еще поди небось за одну посылку ?...

Например одна ось - это 10 бит. Это минимум 2 байта. Тоесть получается передавать нужно за два прохода ..тоесть 80/2=40 раз в сек.

Какая-то у вас интересная математика. 8 байт в одной посылке. По 2 байта на ось это 4 оси в одной посылке. Я в той ветке показывал расчет, что даже если на каждую ось будет свое устройство ввода, т.е. в каждой посылке будет передаваться всего одна ось и накладные расходы максимальные, то за один цикл 80 Гц на скорости 512КБит сможет "высказаться" 101 устройство. Т.е.это 9-кратный запас для 10 осей. 90% времени шина будет простаивать.

У нас все потенциально 65536 осей передаются с частотой 80 герц. Хоть одна , хоть все сразу..

Нет, правда, как вы считаете? 65536 осей помножить на 16 бит (два байта) это уже 1048560, т.е. ваш мегабит, даже без всяких контрольных сумм и прочих накладных расходов. Куда тут еще 80 Гц вставить? Edited September 25, 2009 by САБ

[САБ 444]

в обмотки подается ШИМ с выхода драйвера без всякой фильтрации.

Посмотрел форму тока в обмотках - идеальный синус. Никаких следов ШИМа, т.е. индуктивность обмотки является прекрасным фильтром. Частота ШИМа 7.8КГц.

хитрый метод формирования фазного напряжения

Работает. В расчетах немного ошибся, амплитуда увеличилась на ~11%, на 22% увеличился размах.

[fiyrus 576]

т.е. в каждой посылке будет передаваться всего одна ось и накладные расходы максимальные, то за один цикл 80 Гц на скорости 512КБит сможет "высказаться" 101 устройство.

===

Что то у вас арифметика какая то странная.. Вы посмотрите осцилографом какой длины ваш байт в конечном счете вместе с протоколом самой CAN находится на самой линии. Я что то н енащел в документации имстинную длину пакета и соответственно истинное время занятие шины на момент передачи пакета. Вы не берете в расчет то что будут коллизии. Чем больше устройств тем больше коллизий. Проблемы с реалтаймом начинаются примерно с 5-ти пакетов (5-ти осей ) и коллизии возрастают в арефмитической прогресии с увеличением этих утсройств. Нужно смотреть какой длительностью сам физически пакет CAN после формирования всего на свете. Не забывайте что а автопроме нет задач одновременно передавать данные с частотой 80 герц. Там событийная система - например один раз за поездку передать информацию о закрытых дверях , раз в 2 секунды передать пакет для индикатора масла и тд.. ) При длине 10 байт (именно столько может быть конечная длина вашего байта обрамленного пакетом). 10 байт это 2 мс на скорости 512кбит. Тоесть одна посылка занимает целых 2 мс. Интервал 80 герц - это 0.0125 сек. Тоесть 125 миллисек. 125/2 = 62 пакета умещается в промежуток 80 герц. Это если их четко распределить друг за другом. Но это очень мало для систем с перезапросами! Потому что если одно устройство посылает пакет и второе устройство посылает пакет в интрвале 2мс от начала первого - то пакеты сталкиваются. Уже с двумя устройствами мы гарантировано имеем коллизи в неком фиксированном интервале времени. Три утсройства - три пакета будут вываливатся. и так далее по количеству подключенных модулей. Чем выше частота передачи - тем чаше пакеты сталкиваются. .. В этом случае наступит пауза на шине на перезапрос пакетов. Это уже минимум 2 мс на каждый перезапрос. Во время перезапроса третье устройство посылает пакет и сталкивается с ответом от перезапроса. Я вообще с трудом представляю работу CAN шины в реальном времени хотя бы с 10-ю осями.. Я уже не говорю о потоковой передаче данных. Это всего два устройства. Что будет еслди вы повесите 10 устройств - легко предсказать.. Тоже самое происходит в LAN .. Но извините - там 10 мбит и длина пакета на этой скорости в 20-30 раз меньше вашего ! В этом случае можно расчитывать на реал тайм с 10-ю устройствами. И то, хабы то и дело виснут и тормозят на перезапросах.

Стройте ! Только дам совет - перед тем как тратить средства на изготовление целого копита - проведите эекстрим тест вашей системы на стенде. Зарядите туда скажем хотя бы 20 осей и покрутите все одновременно. Сделайте тестовую утилиту которая показывает все 20 осей одновременно и синхронно покрутите все эти оси...Видео с экрана монитора в студию! Я тогда достану свой стенд и продолжу с CAN шиной в качестве поднания. Может быть мы что то не так делали ?..

Edited September 26, 2009 by fiyrus

[Ghost-V 198]

Что то у вас арифметика какая то странная..

10 байт это 2 мс на скорости 512кбит. Тоесть одна посылка занимает целых 2 мс. Интервал 80 герц - это 0.0125 сек. Тоесть 125 миллисек. 125/2 = 62 пакета умещается в промежуток 80 герц.

Действительно, странная какая-то. Вы бы уже с порядками определились.

[САБ 444]

Что то у вас арифметика какая то странная.. Вы посмотрите осцилографом какой длины ваш байт в конечном счете вместе с протоколом самой CAN находится на самой линии.

Все чудесатее и чудесатее. То есть если теория говорит, что на скорости 512КБит один бит занимает 1/(2^19) =~ 1.9мкс, а осциллограф покажет что-то другое, то верить надо осциллографу? Хорошо, посчитаем еще раз.

Я что то не нашел в документации истинную длину пакета и соответственно истинное время занятие шины на момент передачи пакета.

А я нашел. Открываем описание на CAN-контроллер MCP2515, в нем описаны форматы фреймов. Нас интересует Standard data frame. Накладные расходы: 1 бит - маркер начала, 12 бит поле арбитража, оно же адрес, 6 управляющих битов, 16 бит контрольной суммы, 2 бита подтверждения, 7 битов маркер конца фрейма и 4 бита минимальный межфреймовый интервал. Итого 48 битов накладных расходов. С ними можно передать от 1 до 8 байт полезной информации. Итого на скорости 512КБит получается от 2^19/(48+16) = 8192 фреймов с 2 байтами полезной информации до 2^19/(48+64)=4681 фреймов с 8 байтами полезной информации. Берем худший случай, т.е. 8192, делим на ваши 80 Гц, получаем 102 оси за цикл. Если оси группировать по 8, то int(4681/8) * 8 = 464 оси.

Вы не берете в расчет то что будут коллизии. Чем больше устройств тем больше коллизий.

Естественно. Потому что коллизии разрешаются на аппаратном уровне и приводят лишь к задержке доставки менее приоритетного сообщения. Сколько бы устройств ни создали коллизию, сообщение от наиболее приоритетного не будет разрушено и будет доставлено. То есть если 10 устройств хотят передать свои сообщения, то все эти 10 сообщений будут доставлены за время десяти фреймов.

Проблемы с реалтаймом начинаются примерно с 5-ти пакетов (5-ти осей ) и коллизии возрастают в арефмитической прогресии с увеличением этих устройств.

Такое может произойти только в том случае, если все ваши устройства молотят постоянно, и более приоритетные устройства, постоянно выигрывая арбитраж, задерживают сообщения низкоприоритетных на недопустимое время. Но, извините, зачем молотить постоянно? Отправил пакет, жди следующего 80 Гц цикла. В вашей системе арбитраж разрешается на уровне дополнительного провода выборки на каждое устройство. Т.е. грубой силой (медью и схемой управления ей) вы решаете ту проблему, которая в CAN решается на уровне логики самого протокола.Или вы использовали только физ.уровень протокола CAN, т.е. оконечные драйвера, без контроллера, реализующего канальный, сетевой и транспортный уровни сетевой модели OSI? Тогда становится понятным, откуда коллизии и перезапросы.

Нужно смотреть какой длительностью сам физически пакет CAN после формирования всего на свете.

Не надо смотреть. Надо читать документацию и считать. Расчеты показывают, что времени с запасом.

Не забывайте что а автопроме нет задач одновременно передавать данные с частотой 80 герц. Там событийная система - например один раз за поездку передать информацию о закрытых дверях , раз в 2 секунды передать пакет для индикатора масла и тд.. )

Вот именно. А еще для каждого устройства существует некая макимальная частота, чаще которой данные передавать бессмысленно - они просто не нужны чаще.

Но это очень мало для систем с перезапросами!

Ну нету в CAN перезапросов из-за коллизий. Нету. Есть только если пакет побился помехами, но это ничтожно малая величина. Ghost уже отметил ошибки в порядках. 10 байт на 512КБит это 191мкс.

Стройте ! Только дам совет - перед тем как тратить средства на изготовление целого копита - проведите эекстрим тест вашей системы на стенде. Зарядите туда скажем хотя бы 20 осей и покрутите все одновременно. Сделайте тестовую утилиту которая показывает все 20 осей одновременно и синхронно покрутите все эти оси...Видео с экрана монитора в студию! Я тогда достану свой стенд и продолжу с CAN шиной в качестве поднания. Может быть мы что то не так делали ?..

Ну, крутить оси я вручную не буду, просто заставлю посылать пакеты с нужной частотой. Edited September 26, 2009 by САБ

[fiyrus 576]

Такое может произойти только в том случае, если все ваши устройства молотят постоянно, и более приоритетные устройства, постоянно выигрывая арбитраж, задерживают сообщения низкоприоритетных на недопустимое время. Но, извините, зачем молотить постоянно? Отправил пакет, жди следующего 80 Гц цикла

==

О ! Тоесть всем устройствам на шине нужно знать когда начинается этот цикл опроса так ?...

Я правильно понимаю ?

==

получаем 102 оси за цикл. Если оси группировать по 8, то int(4681/8) * 8 = 464 оси.

====

Что то совсем плохо с расчетами. 464 оси это 7424 байта ПОЛЕЗНОЙ ИНФОРМАЦИИ нужно передать в интервале 1/80=0.0125 сек. Ну никак не пролазит эторасчет в 512 кбит.

 

Давайте посчитаем!

Скорость 512 кбит. Тоесть за 1 секунду мы можем передать 512 тысяч бит.

Но у нас есть пресловутые 80 герц - это полный цикл сбора данных с устройств на шине.

1/80 =0.0125 сек - это время за которое происходит полный цикл. За 0.0125 сек на скорости 512 кбит мы сможем передать 6400 бит или 800 байт. Если брать пакет СAN то чуть меньше половины из них составляет служебная инфомация.Тоесть остается прмерно 448 байт полезной информации за 0.0125 сек. Это всего 25 осей без возможности принимать информацию от тумблеры ..галетники..энкодры..и тд..!!!!

 

забавно у вас получается, 48 бит (6 байт) служебной инфы и 8 байт полезной..мдя.

 

 

Что то я не пойму как вы за один цикл передадите все предполагаемые оси? Если все контроллеры сразу же начнут передавать оси - шина ваша встанет колом потому что все начнут прередавать пакеты одновременно... Или вы сделаете систему синхронизации? И укажете каждому стройству на шине чтобы все устройства передавали пакеты строго друг за другом ?... Что то я не улавливаю смысл всей работы шины. В мануале на CAN сказано что коллизии и решение коллизий это фактически основаная часть работы шины. Столкновения пакетов на этой шине без отдельной системы запросов или опроса устройств отдельной линией гарантировано! Для обнаружения колизий в контроллерах CAN и сделан детектор коллизий полагаясь что о начале посылке данных контроллеры CAN не будут знать заранее. Если два устройства посылают одновременно пакет,их детекторы срабатывают и устанавливается статус коллизии у обоих. В этом случае считается что пакеты не доставлены. Тогда сразу же после обнаружения коллизии одно из устройств с более высоким приоритетом немедленно отсылает пакет повтороно, второй с более низким приоритетом ждет предполагаемое время дл яотправки первым кстройством и отсылает свой пакет следом запервым. Это здорово когда всего висят 2 датчика на шине и посылают пакет раз в 2 секунды. В этом интервале система вполне справляется с повторными посылками.. А у вас же предполагается минимум 3-4 устройства осей каждый будет иметь высший приоритет, потому как оси - они требуют реал тайма и будет не приятно когда РУД опрашивается с 80-ю герцами а РУС с 10-ю , а педали так те вообще раз в секунду..Любые органы управления обделаять временем нельзя никак... Представляете что будет на вашей шине? Один из модулей (при условии отсутствия общего синхросигнала 80 герц) будет хреначить пакеты , второй тоже и третий и четвертый, пакеты будут сталкиватся от всех четырех , в результате большая часть времени будет уходить на перепосылки и ожидания в приоритетах пакетов..сколько на это потребуется время - вы примерно догадываетесь.. Гарантированно в интервале 80 герц будут доходить пакеты от устройства с высшим приоритетом , в два раза реже с приоритетомна шаг ниже и в 3-4 раза реже с приоритетом еще на шаг ниже... Во время перепосылки столкнувшихся пакетов будет готов следующий результат преобразования АЦП и нждно уже будет посылать следующую порцию пакетов.. И процесс с перепосылкой будет повторятся вновь и вновь.. Правильно никаких перезапросов нет! Есть куча пепепосылов которые ставят шину колом. Хрен редьки не слаще. Мы уже смотрели это все осциллографом изучали около месяца эту CAN на экстрим тестах.. Было ощущение что шина самовозбуждалась от этих перепосылок и пока не оставиш два модуля или не снизишь частоту опроса осей примерно до 10ти герц , по шине гуляли коллизии и перезапросы.. Учитывая то что в современных тренажерах придется еще гонять данные c компа в виде дампов блоками по 1 и более килобайт в какиенить внешние FMS или мультидисплеи - то ограничивать себя 512-ю кбитами и 8-ю байтами за 1 фрейм ну простите как то не серьезно...Вам придется как я раньше и говорил разделять шины. Ваш комплекс получается многослойный, состоящий из отдельных шин. Это точно не для симмеров. ПОскольку многие симмеры так и не сумели запустить аппаратную часть простейший EZ_bus. Просто вы сейчас уже себя ограничиваете в расширении системы и будущих возможностях выбирая CAN. Система получится сложной в повторении без промышленного изготовления печаток потому как если брать PIC контроллеры то это 30-я и 33-я серия (это которые здоровые по 50 выводов в SSOP корпусах) с расстоянием между ножек не пригодным к изготовлению ПП в домашних условиях. Проверяйте еще раз не арифметику а реал..В реале ваша система начиная с 4-х реалтайм устройств будет работать хуже мджоя. Проверено! за сим откланиваюсь. Я все чем мог тем помог.

Edited September 27, 2009 by fiyrus

[САБ 444]

О ! Тоесть всем устройствам на шине нужно знать когда начинается этот цикл опроса так ?...

Я правильно понимаю ?

Нет. Ему просто надо делать паузу 1/80 сек. между посылками.

Давайте посчитаем!

Скорость 512 кбит. Тоесть за 1 секунду мы можем передать 512 тысяч бит.

Но у нас есть пресловутые 80 герц - это полный цикл сбора данных с устройств на шине.

1/80 =0.0125 сек - это время за которое происходит полный цикл. За 0.0125 сек на скорости 512 кбит мы сможем передать 6400 бит или 800 байт.

512 кбит это 524288 бит, если быть совсем точными, и 1/80 от этого будет 6553, но порядок верный.

Если брать пакет СAN то чуть меньше половины из них составляет служебная инфомация.Тоесть остается прмерно 448 байт полезной информации за 0.0125 сек. Это всего 25 осей без возможности принимать информацию от тумблеры ..галетники..энкодры..и тд..!!!!

Я сражен. как вы 448 байт поделили на 2 байта/ось и получили 25 осей? Я, конечно тоже ошибся. Худший случай int(8192/80) = 102 оси, лучший - int(4681/80) * 4 = 232 оси.

забавно у вас получается, 48 бит (6 байт) служебной инфы и 8 байт полезной..мдя.

Это плата за удобства, предоставляемые протоколом. Можно было бы передавать и больше полезной информации, но это увеличило бы задержку на доставку самых приоритетных сообщений. В некоторых протоколах бывает, что из 127 бит всего 3 бита информационные.

В мануале на CAN сказано что коллизии и решение коллизий это фактически основаная часть работы шины. Столкновения пакетов на этой шине без отдельной системы запросов или опроса устройств отдельной линией гарантировано! Для обнаружения колизий в контроллерах CAN и сделан детектор коллизий полагаясь что о начале посылке данных контроллеры CAN не будут знать заранее.

Вот в последнем предложении ваше глубокое заблуждение. Благодаря бит-стаффингу любое устройство может определить момент, когда шина занята, дождаться конца фрейма, подождать защитный интервал и только после этого начать передачу. То есть невозможна коллизия типа "другое устройство начало передавать в середине пакета и порушило его". Аналогичный механизм действует и в эзернете. Итак, осталась одна возможность для коллизий - два устройства начали передавать одновременно. Эта та коллизия, которая рушит пакеты в эзернете и из-за которой в эзернете используются повторы с случайной задержкой. В CAN, благодаря передаче бита не нулем и единицей, (которые при одновременной передаче дают неопределенный уровень и ошибку в эзернете), а доминантным (0) и рецессивным (1) уровнями, при передаче двумя устройствами разных битов на шине будет доминантный бит. Тут вступает в действие механизм арбитража. Каждое устройство, слушая шину в момент своей передачи и обнаружив на ней доминантный бит вместо переданного рецессивного, понимает, что в этот момент передает другое (более приоритетное) устройство и прекращает передачу. При этом доминантный бит второго, более приоритетного, устройства остался неразрушенным и оно продолжает передачу. Первое устройство, дождавшись окончания этой посылки, начнет повтор своей передачи. И если в этот раз оно окажется самым приоритетным из всех желающих, его пакет пройдет. Итого, если несколько устройств хотят передать, то их пакеты выстроятся на шине в соответствии с приоритетом. Вот тут есть описание протокола (на английском). Поскольку в нашем случае устройство, передав свой пакет, затыкается на 1/80 сек, то оно в этом цикле больше никому не мешает. И никакой дополнительной синхронизации не нужно.

Учитывая то что в современных тренажерах придется еще гонять данные c компа в виде дампов блоками по 1 и более килобайт в какиенить внешние FMS или мультидисплеи - то ограничивать себя 512-ю кбитами и 8-ю байтами за 1 фрейм ну простите как то не серьезно...Вам придется как я раньше и говорил разделять шины. Ваш комплекс получается многослойный, состоящий из отдельных шин.

Да, две шины. 485 на индикацию (передачу от клиента-симулятора к серверам-устройствам), CAN на управление (передача от клиентов-устройств к серверу-симулятору).

Система получится сложной в повторении без промышленного изготовления печаток потому как если брать PIC контроллеры то это 30-я и 33-я серия (это которые здоровые по 50 выводов в SSOP корпусах) с расстоянием между ножек не пригодным к изготовлению ПП в домашних условиях.

Ой. 18-я серия о 28 ногах, PIC24HJ64GP202 - 28 ног, AT90canХХХ - совсем не монстры. Технология "лазерный утюг" позволяет легко делать в домашних условиях платы с шагом 0.5мм, отдельные умельцы добиваются 0.2мм.

Проверяйте еще раз не арифметику а реал..В реале ваша система начиная с 4-х реалтайм устройств будет работать хуже мджоя. Проверено!

"Пожуем, увидим" Перед тем, как хвататься за паяльник и двигать байты, надо все хорошенько обдумать, постараться предугадать подводные камни. Чем я сейчас и занимаюсь. Edited September 27, 2009 by САБ

[fiyrus 576]

О ! Тоесть всем устройствам на шине нужно знать когда начинается этот цикл опроса так ?...

Я правильно понимаю ?

Нет. Ему просто надо делать паузу 1/80 сек. между посылками.

==

Если каждое устройство будет делать паузу и каждое устройство будет стартовать без единого опорного генератора 80 гец , их фазы спауз и стартов будут совпадать кратно разнице частоты квалцевыз резонаторов. Кварцевые резонаторы всегда имеют нестабильность. Разница в 1-2 герца всегда есть. Это примерно каждый 160-й посыл будет иметь коллизию.

Вам нужно будет синхронизировать фазы отправки пакетов для всех устройств. Тогда устройство 1 оправляет пакет немедленно, устройство 2 спустя 1.6 мс , устройство 3 - 3.2 мс и так далее до конца заполнения тайм слотов или фреймов как угодно. Как только наступил синхросигнал - цикл повторяется.. Этот сигнал можно гонять по шине от какогонить задающего контроллера....Впринципе должно работать..

Я только так вижу работу такой системы. Тоесть должен быть кто то ведущий-отсчитывающий-говорящий всем устройствам о начале цикла опроса. Просто ума не приложу как вы будете обяснять устройствам что настало время нового цикла для сбора информации ? Только не говорте что у каждого устройства будет свой внутренний генератор 80 гец который синхронизируется 1 раз по подаче питания скажем..

Edited September 27, 2009 by fiyrus

[САБ 444]

Тоесть должен быть кто то ведущий-отсчитывающий-говорящий всем устройствам о начале цикла опроса. Просто ума не приложу как вы будете обяснять устройствам что настало время нового цикла для сбора информации ? Только не говорте что у каждого устройства будет свой внутренний генератор 80 гец который синхронизируется 1 раз по подаче питания скажем..

Похоже, вы не читаете того, что я старательно расписываю. Да, каждое устройство будет само генерить для себя 80Гц цикл. Ни с кем не синхронизованный. Если в момент завершения этого цикла идет передача чужого пакета, контроллер CAN ожидает окончания передачи и пытается передать свой пакет. Если он самый приоритетный из желающих - он свой пакет отправит. Если нет - проиграет арбитраж и повторит попытку. Как только отправил - начинает отсчет нового цикла. Т.е. синхронизаия получается автоматически, менее приритетное устройство "пропускает вперед" более приоритетное, но в цикле остается еще куча времени, чтобы все устройства успели передать свою информацию, выстроившись в очередь по приоритету.

Ну вот совсем на пальцах:

Есть четыре устройства: A, B, C и D. Устройство C захотело передать информацию (шина свободна) и начало передачу. Пока оно передает, захотели устройства A, B и D. Они видят, что шина занята и ожидают окончания передачи C. Передача закончилась и они все втроем ломанулись передавать. Одновременно. На этапе передачи адреса (поле арбитража) выиграло устройство A, как имеющее меньший адрес и, значит, более высокий приоритет. Оно передает свой пакет, B и D ждут окончания передачи. Передача закончилась, B и D начинают передачу. Арбитраж выигрывает B, передает свой пакет. D дожидается окончания передачи и передает свой - ему уже никто не мешает. Итого на передачу четырех пакетов затрачено время, равное длине четырех пакетов. И до конца цикла еще осталась куча времени.

Я не знаю - как еще понятнее объяснить.

[Evgeny_ 1]

Извините что вмешиваюсь. Насчет неразрушающей коллизии в CAN САБ абсолютно прав. В том что шины реализованы даже в 18 серии - я давал ссылку на мануал в соседней ветке. Синхронизация, мне кажется, абсолютно не нужна, правильно пишет САБ, при опросе 80 Гц не имеет значения даже при одновременном событии двух устройств какое из них передаст информацию первым - ведь система (самолет) несопоставимо инерциальна. Мне кажется, Олег, Вы отбросили эту шину потому что у Вас что-то не пошло на ней а подсказать было некому, но в целом, на мой взгляд, хотя САБ и ерошится на мои посты, мне кажется его идея жизнеспособна и то что он явно прочитал мануал по шине - вселяет надежды в успех его мероприятия. А Ваш опыт практического кокпитостроения ему очень пригодится, но думаю не в обсуждении чья шина круче, а в том какие скорости опроса, какое количество осей и прочих устройств надо закладывать при проектировании. Не ссорьтесь, господа. Сколько научных школ - столько мнений по одному вопросу.

[fiyrus 576]

Мне кажется, Олег, Вы отбросили эту шину потому что у Вас что-то не пошло на ней а подсказать было некому,

==

Я отбросил ее по одной причине - мне (для моего понятия реал тайма) на экстрим тесте (когда пакеты шпарили от 6 предполагаемых модулей осей с частотой 80 герц) мне на этом тесте показалось не стабильная работа всей шины. Тоесть уже было под завязку на самой шине по осциллографу и проходы некоторых пакетов застревали до 0.1 сек. Что давало некий довольно ощутимый фриз всей шины. Возможно у вас будет иначе. Представьте - 80 герц это 0.0125 сек - тоесть почти в 5 раз меньше времени реакции мозга человека. Если брать голый тест осей в ПК и крутить ручку на железке то реакция на начало поворота и получения результата на экране с 80-ю герцами была молниеносная.Это при уловии что на шине одно устройство по 4 оси. Добавляем еще точно такое же устройство в режиме эмуляции оси - тоесть оно посылало пакет автоматом точно также как себе это представляет САБ - без синхрона. Время реакции тестовой ручки было в норме. Как только добавили 5-е утсройство - всё. Кирдык. Начались заметно ощутимые фризы. Дальше хуже 6-е устройство вешало шину примерно на 0.1-0.2 сек. Неотъемлемое условие построения шины для реалтайм сбора инфы - никаких приоритетов! Все усьтройства должны четко и гарантировано отсылать пакеты с частотой 80 герц. Как музыкальный оркестр - играть четвко и слажено не нарушая ритма (80-ти герц).. Как выглядят эти фризы - предстаьте у вас на экране плавнейшая 3D картинка со скоростью 80FPS. И потом бах - фриз на 3-4 кадра. .В симуляторе мы это видим постоянно. Ничто не бесит глаз и вообще ничто так не раздражает психику как эти фризы. Возможно для вас это ничто и вы не заметите фриз длиной 0.5 секунд, но ситему делаем не для себя а для массы людей среди кторых есть те кто замечает фризы в 0.05 сек. (у нас уже есть такие заказчики которые выбросили Мджоеевские энкодры именно из за такой фризово-лаговой работы). Из за фризов на экране приходится лочить FPS на 30-ти кадрах только чтобы не видеть эти тормоза. Тоже самое происходило и с тестовой осью - все плавно плавно а потом херак - фриз...один..другой.. Я незнаю как себя будет вести модель самолета если его РУС замораживавть на такое время. не знаю какой фриз будет у кнопок и тем более у энкодеров если вращать РУС педали и РУД (это миниму 2 устройства на шине). Сам факт наличия лагов и фризов поставил точку в дальнейшем исследовании шины. Дальше хуже .. Учитывая то что в подобных фреймовых системах вся "колбаса" попадает в буффер , и там копится то появляются очереди пакетов создавая задержки как в самой системе так и в софте. Для обработки входящей информации в ПК нужно время - а это время как минимум 1/80 секунда в лучшем случае как у нас а максимум - до бесконечности. С фризами это время было бы не предсказуемым вообще. Далее - работая с FSUIPC вывели очень большой его баг - там обноавлять переменный можно не так часто.. Тоесть будет заведомо большой лаг от поворота ручки на железе до реакции модели самолета. Если еще и железо будет тормозить то такая система даром не нужна ни кому. Хором вспоминает качество работы энкодроы мджоя.

И еще не забываем что ARCC это коммерческое мероприятие. Нас не интересуют дорогие по себестоимости системы которые из за большой цены нельзя продать на российском рынке. Скажу так - сейчас при заявленной стоимости нашего железа я получаю чистой прибыли чтобы ровно сходить за пивом с одногокомплекта плат. Тоесть чисто символическая прибыль. Делая систему на CAN , конечная стоимость возрасла бы в разы. Например модуль осей стоил бы не 1200р а скажем 3100р. Базовый блок уже бы имел совсем иную конфигурацию и стоил бы под 4-4.5 тыщи рублей. Тоже самое коснулось бы всех остальных модулей и цена сровнялась бы с ценой плат от СИМ-КИТ или IOcards где за 6 осей просят 100 евро. http://www.simkits.com/product.php?prodid=607 Почему так? Потому что в стоимость была бы заложена отладка всего комплекса а это очень не малое время.

Что касаемо фришных проектов.Из практики многолетних наблюдений всех их ждет учесть ПТ и FSBUS. Поверьте, энутзиазм заканчивается с началом массовости и повторяемости. Будет очень больно смотреть как ваш комплекс повторяют сотни людей , а вам в кошелек пустой ноль. Имя? "Имя в тарелкене побулькаешь"... Да еще несколько лет подряд будут требовать БЕСПЛАНО фиксить найденные баги и требовать новые версии прошивок! Не сделаете - обольют грязью!.. Увы. Специфика рынка. Из за того что наша ARCC не бесплатная система - морально перед заказчивами я обязуюсь фиксить и фиксить баги (если они конечно еще найдуися),и обязуюсь обеспечивать техподдержку проекта до последнего клиента.

Edited September 28, 2009 by fiyrus

[Evgeny_ 1]

Делая систему на CAN , конечная стоимость возрасла бы в разы. Например модуль осей стоил бы не 1200р а скажем 3100р.

Олег, а если отбросить эмоции и гипотетически предположить достаточность скорости CAN, - почему Вы считаете, что цена так сильно возрастет из-за использования встроенных в ПИК CAN интерфейсов? Только из-за сложностей отладки?

 

Кроме того, меня не покидает мысль о использовании цветных графических экранов в приборах. Согласитесь, если бы создать прибор стандартного размера, который нажатием кнопочек на задней крышке становится или высотомером или индикатором спуск-подъем... И имеет всего два разьема - вход-выход шины, пусть то ARCBus или CAN - не важно. И цена такого прибора в пределах 2т.р. - мне кажется это была бы сильная альтернатива оживлению чего бы там ни было на базе сельсинов или вакуумных камер.

[САБ 444]

Тоесть уже было под завязку на самой шине по осциллографу и проходы некоторых пакетов застревали до 0.1 сек.

Если не коммерческая тайна, сколько полезной информации у вас при этом передавалось?

Неотъемлемое условие построения шины для реалтайм сбора инфы - никаких приоритетов! Все усьтройства должны четко и гарантировано отсылать пакеты с частотой 80 герц. Как музыкальный оркестр - играть четвко и слажено не нарушая ритма (80-ти герц)..

То есть если за 1/80 сек все подключенные устройства успеют передать свою информацию (неважно в каком порядке - важно что 80 раз в секунду мы получаем по одному сообщению от каждого из устройств), то такую систему можно считать жизнеспособной?

Делая систему на CAN , конечная стоимость возрасла бы в разы. Например модуль осей стоил бы не 1200р а скажем 3100р. Базовый блок уже бы имел совсем иную конфигурацию и стоил бы под 4-4.5 тыщи рублей. Тоже самое коснулось бы всех остальных модулей и цена сровнялась бы с ценой плат от СИМ-КИТ или IOcards где за 6 осей просят 100 евро.

Опять же, если не коммерческая тайна, где можно ознакомиться с функциональностью ваших модулей, например модуля осей? Стоимость контроллера CAN порядка 3$ + 1$ драйвер. Программировать его примерно настолько же сложно, как и написать поддержку протокола общения по UART, а то и проще, ибо канальный и сетевой уровени протокола уже реализованы в контроллере. Фактически передача заключается в "сложить данные в буфер по SPI, дать команду на отсылку", а прием - "получили прерывание, считали статус, считали данные". Для связи по UART эти оба уровня нужно реализовывать программно. Я не вижу тут увеличения стоимости в разы. Вы же еще дополнительно используете профода синхронизации, а это медь, это схемы их раскачки, по-хорошему - схемы защиты входов. Конечно, если есть большие наработки, они существенно снижают себестоимость разработки. Свои наработки по RS-485 я адаптировал под прибор в первом посте за прошедшие выходные. Действительно, будет интересно посмотреть, сколько времени займет победа над драконом CAN. Сможем оценить.

 

Поверьте, энутзиазм заканчивается с началом массовости и повторяемости. Будет очень больно смотреть как ваш комплекс повторяют сотни людей , а вам в кошелек пустой ноль. Имя? "Имя в тарелкене побулькаешь"...

Поставите пиво, если позаимствуете что-то из моих результатов?

P.S. Я уже участвую в одном небольшом открытом проекте и еще в одном принимал участие. Отрицательных эмоций пока не получил. Есть большой плюс - участникам нечего делить, есть только чем поделиться.

Edited September 28, 2009 by САБ

[fiyrus 576]

Олег, а если отбросить эмоции и гипотетически предположить достаточность скорости CAN, - почему Вы считаете, что цена так сильно возрастет из-за использования встроенных в ПИК CAN интерфейсов? Только из-за сложностей отладки?

==

И не только...Посмотрите буржуйские USB аналоги наших модулей. Онистоят в разы дороже! И не потому что там зарплаты выше а потому что используются платные и довольно дорогостоящие среды разработки. За них (всяко рода библиотеки стеки , отладчики , программаторы, компилляторы и тд ) платили и не малые деньги. Попробуйте в цивилизованной стране самостоятельно начать производство для продажи какогонить устройства. Вас попросят предостваить всю лицензию на софт начиная от винды , заканчивая средой разработки. И попробуйте предоставить лицензию от вашего предприятия , сразу же будет доложено вашему начальству о не целевом использовании оборудования вашей фирмы.

==

И цена такого прибора в пределах 2т.р. - мне кажется это была бы сильная альтернатива оживлению чего бы там ни было на базе сельсинов или вакуумных камер.

==

думали об этом.. Пока в розницу цена такого экранчика цветного стоит в пределах 3000 р. Да и рынок этих эеранов стремительно меняется так что одни срубают бабло на продаже DVD плееров или чего то там а други пока отладят все как следует экраны поменяютна чтонить еще другое не совместимое.. И так будет до бесконечности..

===

 

 

Если не коммерческая тайна, сколько полезной информации у вас при этом передавалось?

===

всего 4 байта. Тоесть 2 оси.

==

То есть если за 1/80 сек все подключенные устройства успеют передать свою информацию (неважно в каком порядке - важно что 80 раз в секунду мы получаем по одному сообщению от каждого из устройств), то такую систему можно считать жизнеспособной?

==

В мемпонимании - да. В понимании создателя скажем М-джоя+энкодеры или систему сбора FSBUS с линий Busy - для них это оч завышенный параметр. Особенно для дядек из майкрософта , где долгое время подсистема джоя работала на 10-ти герцах , а синтез звука через DirectSound подсистему задерживается на 1.5 секунды от события нажатия ноты на клавиатуре. Для ниъ это считается нормой.

===

Опять же, если не коммерческая тайна, где можно ознакомиться с функциональностью ваших модулей, например модуля осей?

==

Вам наверное лень почитать мою подпись под сообщениями.. Там же адрес.

И кстати, железо - это 1 скажем ..1/10 части всего пе..ца с которым придется столкнутся..

Читайте подпись внимаьльено - без человеческой работы с переменными всё преимущество железа сводится на нет..!

Эту тему я еще не затрагивал..

==

СAN порядка 3$ + 1$ драйвер.

==

 

Очень большая разница между предполагаемой стоимостью железа которое на макетке и конечной продукцией на нормальных платах в человеческом виде с устаканеной ценой и огромными времязатратами на "полировку" прошивок. Полировали уже сколько..года полтора точно..Между двумя этими понятиями стоит слово "производство".. наверняка всем известно что это такое и сколько стоит это в нашей стране.

http://www.arccpro.narod.ru/main_page7.htm

http://www.arccpro.narod.ru/maun_page6.htm

http://www.arccpro.narod.ru/main_page8.htm

http://www.arccpro.narod.ru/index_page26.htm

http://www.arccpro.narod.ru/index_page14.htm

и тд..

Техн характеристики там же.

Edited September 28, 2009 by fiyrus

[LISА 25]

Авиация это духовная ценность, материальную сторону мы тут не обсуждаем!

[fiyrus 576]

F16 стоит около 25 миллионов $ ... Боинг 747 примерно столько же..

Тренажер бобика от CAE - около 2-х лимонов$...

==

Джойтик SAITEK примерно 250$...педали столько же.. Любимые авиационные часы стоящие на столе рядом с джойстиком - около 150$...Всё остальное - "духовная ценность" которая не имеет цены..

Да..авиация точно бесценна даже виртуальная !

Edited September 28, 2009 by fiyrus

[Sly 0]

О здорово, и меня приплели сюда

[fiyrus 576]

О здорово, и меня приплели сюда

 

А вот и выяснили у кого авиачасы на столе тикают :-D

[Sly 0]

А вот и выяснили у кого авиачасы на столе тикают :-D

 

Причём не одни

[Evgeny_ 1]

думали об этом.. Пока в розницу цена такого экранчика цветного стоит в пределах 3000 р. Да и рынок этих эеранов стремительно меняется так что одни срубают бабло на продаже DVD плееров или чего то там а други пока отладят все как следует экраны поменяютна чтонить еще другое не совместимое.. И так будет до бесконечности..

Не думаю. Там всего сейчас 3 интерфейса: т.н. MCU - он же обычный 8 бит данных плюс 4 управляющих сигнала, 18-битный и RGB аналоговый. Первый не многим сложнее обычных текстовых ЖКИ. Минус - маленькая производительность и как следствие максимум 160х160 или эквивалент. Второй - он же цифровой (digital-18), он характерен для высокопроизводительных цветных дисплеев от 320х240 и выше. Аналоговый - просто три аналоговых входа РЖБ и несколько линий синхронизации и сброса. Для наших целей имеет смысл смотреть только на второй тип. Он бывает реализован на нескольких контроллерах (Самсунг, Хитачи, Тошиба) но суть его не меняется - фактически это попиксельный вывод всего экрана как на ЭЛТ. Т.е. необходимо 30 раз в секунду нарисовать весь дисплей, последовательно задвигая в него данные. Есть нюансы, в частности можно еще читать данные с дисплея, можно использовать встроенный генератор шрифта и курсора, но это все убого, и если делать это по уму (читай плавно и красиво) то это делать в контроллере. Не думаю что за ближайшие несколько лет это изменится. Все КПК и встроенные системы сейчас используют шину Диджитал-18, на нее есть библиотеки, разработанные и вылизанные контроллеры СОВМЕСТИМЫЕ МЕЖДУ СОБОЙ, да и производительность у нее достаточна для 800х600 при частоте 60Гц. Так что опасаться что производители ДВД что-то придумают я думаю не стоит - если они что и меняют, то в своем аналоговом сегменте, и гонятся в основном за пикселями, чего нам не требуется по определению. Наш сегмент ИМХО будет и далее совместим вниз, тем более как я уже написал проще чем диджитал-18 трудно придумать шину да и не надо вовсе, как не меняется уже 11 лет интерфейс HITACHI HD 44780 текстовых LCD дисплеев (разработан и принят в 1998 году). Может я конечно ошибаюсь, но мучает меня идея все же попробовать.

[fiyrus 576]

Идея есть.. почему бы не заюзать тарые БУ КПК для этих целей ?..

Там все есть - камень от 200 мгц , RAM , нормальная OC и огромная куча бидлиотек и сред разработки. Причем есть нормальные эмуляторы для PC ..

Тело прибора помещаем в КПК , его дизайи и шкалу , экран КПК обрамляем бутафорской мордой от реального прибора. Даные в КПК можно гонять хоть по USB хоть через эмуляцию COM хоть через Wi-Fi ..там где она есть конечно..Мне кажется это самый дешевый варинат.

Если мешает геометрия экрана и она или не вписывается в габариты прибора или заведомо больше - подбирается ссотв тип экрана с Диджитал-18 шиной и вперед! Я правильно понимаю ?...

Вот например есть готовое решение..Правда оч дорого

http://www.avionicslcd.com/3.5_inch_VGA_LCD/3.5_inch_VGA_Hand_Hold_LCD_Display.htm

Edited September 29, 2009 by fiyrus

[ra3dcs 461]

Что касаемо фришных проектов.Из практики многолетних наблюдений всех их ждет учесть ПТ и FSBUS. Поверьте, энутзиазм заканчивается с началом массовости и повторяемости. Будет очень больно смотреть как ваш комплекс повторяют сотни людей , а вам в кошелек пустой ноль. Имя? "Имя в тарелкене побулькаешь"...

 

Как же Вы Олег этого страшно боитесь!!!!!